【Informatica】CIHの権限周りの仕様を確認して、最適なフォルダ構成を検討してみる
2024.10.16はじめに
データ事業本部の川中子（かわなご）です。
今回は Cloud Integration Hub (以降CIH)における権限の仕様について確認し、
考えられるフォルダやアセットの配置構成について考えていきたいと思います。
なお本記事では検証方法として、API経由のパブリケーション実行を行っています。
API経由での実行方法について詳細を確認したい方はこちらの記事を参照して下さい。
今回の大きなテーマは以下のようになっています。
- CIHにおける権限の仕様を確認
- 考えられるフォルダの構成を検討
権限の設定
InformaticaのCIHにおいて権限を操作するには、以下の3つが関わってきます。
- 管理者：ユーザー/ロール設定
- 管理者：ユーザーグループ設定
- CIH：フォルダやアセットごとの設定
ユーザー/ロール設定
こちらは管理者画面から作成・設定することができます。
今回は検証用のユーザーとして、「くらすめそお」さんを作成しました。
検証用ユーザーには、CIHを利用するうえで必要な権限を全て付与しています。
なおCIHを利用するために必要なロールについては、以下のドキュメントを参照して下さい。
ユーザーグループ設定
こちらも管理者画面から作成・設定することができます。
ここで作成したグループに対しても、CIHを利用するうえで必要な権限を全て付与し、
検証用ユーザーにはgrp_test_projectBというグループ権限をアタッチしています。
フォルダやアセットごとの設定
CIHの参照画面において、フォルダや各アセットに対しても個別に権限を設定できます。
この設定により、 ユーザーやグループに対して、閲覧や変更、実行などの操作を制限 できます。
今回はこれらの権限設定の仕様について、いくつかの検証を行ってみたいと思います。
権限の仕様検証
今回の検証では以下のようなケースを想定してアセットを作成しています。
トピックは専用のプロジェクトフォルダ下に配置して、3つのプロジェクトを別で作成しました。
グループとユーザー単位の権限はどちらが優先されるか
まずはサブスクリプションなどのアセットに対して権限を設定する際に、
グループとユーザー、どちらの権限設定が優先されるかを見てみます。
プロジェクトBにあるサブスクリプションに対して、グループ単位では実行権限を付与し、
ユーザー単位では実行権限を外して、検証用ユーザーでAPI経由の実行をしてみます。
結果としては、サブスクリプションを実行するための権限がないためにエラーになります。
この結果から、 ユーザー単位の権限は、グループによる権限より優先される ことが分かります。
プロジェクト内のメンバーで、閲覧権限のみを与えたいユーザーがいる場合などは、
そのユーザーのみ追加でユーザー単位の権限を設定すれば、簡単に制限がかけられそうです。
フォルダとアセット単位の権限はどちらが優先されるか
次に、フォルダやアセットに対して権限を設定した場合、どちらが優先されるのかを見てみます。
プロジェクトCのフォルダにはグループCの権限のみ付与されており、
検証用ユーザーには一切の権限が付与されていない状態になっています。
この条件でプロジェクトCフォルダ下にあるパブリケーションを開こうとすると、
フォルダ自体を開くことはできますが、パブリケーションの設定画面を開くことはできません。
検証用ユーザーでAPIからパブリケーションを実行しようとしても、
同じく権限エラーによって実行することはできません。
しかしこの状態から、以下のようにパブリケーションへグループBの読み取り権限を追加すると、
問題なくパブリケーションの設定画面を開けることも確認できました。
この結果から、 アセット単位の権限は、フォルダに対する権限より優先 されることが分かります。
トピックに対する権限設定による操作制限
次にトピックに権限を設定して、権限を持たないプロジェクト(ユーザー)から、
パブリケーション作成時にトピックを指定しようとした際の仕様を確認します。
実際にパブリケーションの設定画面を見てみると、やはりトピックを選択することはできません。
権限の仕様まとめ
ここまでの権限仕様の検証から分かったことをイメージにすると、以下のようになります。
-
権限の優先順位は「ユーザー > グループ」、「アセット > フォルダ」になる
-
権限がないフォルダに対しては、閲覧や実行、トピックの指定ができない
仕様を踏まえたフォルダ構成の考察
CIHにおけるフォルダ構成のパターンとして、大まかに以下の3つについて考えてみました。
- トピックがパブリケーション側のプロジェクトフォルダ配下に存在する
- トピックが専用のプロジェクトフォルダに存在する
- 全ての関連アセットが1つのプロジェクトフォルダ配下に存在する
トピックがパブリケーション側のプロジェクトフォルダ配下に存在
- メリット：
- トピックの 管理責任の所在が明確
- トピックを使用しないプロジェクトからの閲覧や実行を制限できる
- フォルダにグループの権限を付与すれば、あとは個別にトピックへの権限付与だけすればよい
- デメリット：
- トピックを使用するプロジェクトが増えるたびに、トピックへ権限付与が必要
- 複数プロジェクトで同じトピックにパブリッシュする場合に管理が煩雑
この構成の場合、基本的にプロジェクトAのフォルダにはグループAの権限を付与し、
トピックには、トピックを使用する他グループの読み取り権限のみ付与する流れになります。
トピックに対してパブリッシュするプロジェクトが1つだけの場合 は、比較的管理がしやすいです。
トピックが専用のプロジェクトフォルダに存在
- メリット：
- トピックの 管理責任をプロジェクトとは別のチームで持つ ことができる
- 複数プロジェクトからのパブリッシュの場合も管理が煩雑になりにくい
- トピックを使用しないプロジェクトからの閲覧や実行を制限できる
- デメリット：
- トピックを使用するプロジェクトが増えるたびに、トピックへ権限付与が必要
- トピックを管理する 責任者を決めるためのルールが別で必要 になる
1つのトピックに対して、複数プロジェクトからパブリッシュすることがある場合は、
トピックを別フォルダで管理するこの方法が候補として挙がります。
しかしその場合は トピックを誰が管理しているのか、ルールを明記する必要 が出てきます。
また前項目と同様、トピックに対しては個別に権限の設定が必要になります。
全ての関連アセットが1つのプロジェクトフォルダ配下に存在
- メリット：
- 最初に関連チーム・メンバーの権限を整理すれば、以降は都度の権限設定が不要
- デメリット：
- プロジェクトフォルダ配下には、 1階層分しかフォルダを分けられない
- 1つのプロジェクトフォルダのみ膨大な量になる
- リリース作業時、リリース範囲が若干分かりづらい
このフォルダ構成は、CIH内のプロジェクト間で閲覧などの制限をかけない場合に考えられます。
しかし全てのアセットをプロジェクトフォルダ内でバラバラに作成すると管理が難しく、
ある程度の単位でフォルダを分けるにしても、フォルダは1階層分しか作れません。
CIHで管理する想定の範囲が狭い場合は、このような管理方法から始める選択肢もありますが、
ある程度閲覧などを制限する要件がある場合には、上2つの方法から選ぶのが良いと思います。
その他のパターン
そもそもプロジェクトを跨いだトピックの利用を想定しない場合には、
1つのプロジェクト内に全てのアセットを作成する管理方法で特に問題ないと思います。
またアプリケーション単位や、マッピング(タスク)単位で管理を分ける方法も考えられますが、
大まかには上記の方法に大別されると考えているので、今回は省略しています。
フォルダ構成考察のまとめ
フォルダ構成を検討するうえでは、以下の2点を最初に考える必要がありそうです。
- 1つのトピックに対して複数プロジェクトからパブリッシュすることがあるか
- ある場合：トピックを管理するフォルダを独立させる
- ない場合：パブリケーションなどのアセットとトピックを共存してもよい
- トピックの管理責任は誰が持つか
- パブリケーション側：パブリケーションなどのアセットとトピックを共存してもよい
- 別チーム：トピックを管理するフォルダを独立させる
権限の設定については、プロジェクトごとのユーザーグループを作成しておけば、
各トピックやフォルダの権限設定を大幅に簡略化することができます。
さいごに
CIHを使用する場合、テーブル情報を持つトピックがGUI上で管理されるため、
どのプロジェクトメンバーに、どこまでの権限を付与するかを整理することが重要 です。
権限の整理をするうえでは、 ユーザーグループによる整理がとても有効 なので、
どのような単位でユーザーグループを作成するのか、から検討するのがよいかも知れません。
これからCIHを導入する方、権限周りの設定を見直したい方などのご参考になれば幸いです。
最後まで閲覧頂きありがとうございました。
